Skip to content

HYPERFLEET-1231: align error-model.md detail field with RFC 9457 and TypeSpec#175

Merged
openshift-merge-bot[bot] merged 1 commit into
openshift-hyperfleet:mainfrom
kuudori:HYPERFLEET-1231-detail-field-alignment
Jun 29, 2026
Merged

HYPERFLEET-1231: align error-model.md detail field with RFC 9457 and TypeSpec#175
openshift-merge-bot[bot] merged 1 commit into
openshift-hyperfleet:mainfrom
kuudori:HYPERFLEET-1231-detail-field-alignment

Conversation

@kuudori

@kuudori kuudori commented Jun 26, 2026 •
edited by Mischulee
Loading

Copy link
Copy Markdown
Contributor

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

@kuudori
HYPERFLEET-1231 - fix: align error-model.md detail field requirement …
e91e92a 
…with RFC 9457 and TypeSpec

The Standard Fields table marked `detail` as Required=Yes, contradicting
both RFC 9457 (SHOULD, not MUST) and the TypeSpec definition (`detail?: string`).
Relax to Required=No and add SHOULD guidance to preserve the practical
expectation that implementations always populate the field.
@openshift-ci-robot

openshift-ci-robot commented Jun 26, 2026 •
edited by atlassian Bot
Loading

Copy link
Copy Markdown

@kuudori: This pull request references HYPERFLEET-1231 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci

openshift-ci Bot commented Jun 26, 2026

Copy link
Copy Markdown

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci-robot

openshift-ci-robot commented Jun 26, 2026 •
edited by openshift-ci Bot
Loading

Copy link
Copy Markdown

@kuudori: This pull request references HYPERFLEET-1231 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@coderabbitai

coderabbitai Bot commented Jun 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor
📝 Walkthrough

Walkthrough

Updated hyperfleet/standards/error-model.md with a new “Last Updated” date and revised the RFC 9457 detail field guidance from required to optional, while adding text that implementations SHOULD still populate detail. No code paths or public entities changed. No CWE/CVE IDs are implicated.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 11
✅ Passed checks (11 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the change: making error-model.md's detail field optional and aligning it with RFC 9457 and TypeSpec.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Sec-02: Secrets In Log Output ✅ Passed PASS: PR is doc-only; no non-test/example slog/logr/zap/fmt.Print* calls with token/password/credential/secret found (CWE-532).
No Hardcoded Secrets ✅ Passed No hardcoded creds found; the PR only changes markdown docs, and scans found no user:pass@ URLs or literal apiKey/secret/token/password assignments (CWE-798).
No Weak Cryptography ✅ Passed PASS: docs-only change; no crypto imports/usages, no SHA1/MD5/DES/RC4/ECB, and no secret comparisons found (CWE-327).
No Injection Vectors ✅ Passed Only Markdown docs changed; diff has no exec.Command/template.HTML/yaml.Unmarshal/fmt.Sprintf query patterns.
No Privileged Containers ✅ Passed PASS: PR only changes Markdown docs (error-model.md et al.); no K8s/OpenShift manifests, Helm templates, or Dockerfiles were modified, so no CWE-250/CWE-269 privilege issue.
No Pii Or Sensitive Data In Logs ✅ Passed No CWE-532/CWE-209 issue: the touched doc logs only generic error text, path, field, and trace_id—no PII, secrets, or raw bodies.
Description check ✅ Passed The description matches the doc change to make detail optional while preserving SHOULD guidance.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
✨ Simplify code
  • Create PR with simplified code

Comment @coderabbitai help to get the list of available commands.

@openshift-ci-robot

openshift-ci-robot commented Jun 26, 2026 •
edited by openshift-ci Bot
Loading

Copy link
Copy Markdown

@kuudori: This pull request references HYPERFLEET-1231 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@kuudori kuudori marked this pull request as ready for review June 26, 2026 19:17
@openshift-ci openshift-ci Bot requested review from tirthct and vkareh June 26, 2026 19:17
@Mischulee

Mischulee commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

/lgtm

@openshift-ci openshift-ci Bot added the LGTM label Jun 29, 2026
@openshift-ci

openshift-ci Bot commented Jun 29, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Mischulee

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot

openshift-ci-robot commented Jun 29, 2026 •
edited by openshift-ci Bot
Loading

Copy link
Copy Markdown

@kuudori: This pull request references HYPERFLEET-1231 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

1 similar comment
@openshift-ci-robot

openshift-ci-robot commented Jun 29, 2026 •
edited by openshift-ci Bot
Loading

Copy link
Copy Markdown

@kuudori: This pull request references HYPERFLEET-1231 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Relaxes detail field from Required=Yes to Required=No in the Standard Fields table of error-model.md
  • Adds SHOULD guidance below the table preserving the expectation that implementations always populate detail
  • Aligns the standard doc with TypeSpec (detail?: string), generated OpenAPI (required: [type, title, status]), and RFC 9457 Section 3.1 (SHOULD, not MUST)

Why

ADR-0003 establishes TypeSpec as the single source of truth for the API contract. The standard doc's Required=Yes contradicted both TypeSpec and RFC 9457 without documented justification. All existing implementations already populate detail via constructor patterns that require a reason string — this change is documentation-only with no behavioral impact.

Ticket: HYPERFLEET-1231

Verification

Source Field Status
error-model.md (this PR) Required=No + SHOULD prose updated
TypeSpec (model.tsp) detail?: string already optional
Generated OpenAPI required: [type, title, status] already excludes detail
RFC 9457 Section 3.1 SHOULD language aligned

Test plan

  • Markdownlint passes
  • Reviewer confirms alignment with TypeSpec definition
  • Reviewer confirms SHOULD prose is sufficient guardrail

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-merge-bot openshift-merge-bot Bot merged commit e7c3899 into openshift-hyperfleet:main Jun 29, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@tirthct tirthct Awaiting requested review from tirthct
@vkareh vkareh Awaiting requested review from vkareh

Assignees

@Mischulee Mischulee

Labels

approved LGTM

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@kuudori @openshift-ci-robot @Mischulee